REMARKS 

Claims 1-20 are still pending in this application. The Examiner has rejected claims 1-20 
under 35 U.S.C. §103 as being unpatentable over Tushie et al. {Tushie) in view of Harms. 
Claims 1 and 1 1 have been amended to further clarify the claimed invention. 

As a first step, claim 1 specifically requires 

executing a personalization assistant software tool, said software tool including a 
default member profile having default values for smart card features. 

The term "smart card features" has a particular meaning as explained in the specification. 
"Smart card features" refers to features of a smart card. A "member profile" is a profile of a 
particular member that has default values for the smart card features. The cited portions of 
Tushie do not disclose "a smart card personalization software tool including a default member 
profile having default values for smart card features." The Office Action apparently relies upon 
issuer format template data and the card framework template record as disclosing this step. 

For example, column 2 of Tushie discloses issuer format template data. Column 17 
makes clear that a data format template is used to translate data fields into an internal order. An 
example data format template record is shown in column 17 at line 30. As shown (and as 
explained later in that same column), the template record simply holds an internal label to show 
how to order cardholder data internally. It is not a profile of a particular member. It does not 
have default values for smart card features. It simply holds ordering information to rearrange 
cardholder data. Further, claim 1 specifically requires in a fifth step that the default member 
profile is modified based upon user input. The data format template record as shown in column 
18 is never modified based upon user input. It has static values. If the Office Action assumes 
that the data format template record is a member profile, then there is a problem with that 
analogy because the fifth step of claim 1 requires that the default member profile is modified. 

The same problem surfaces with an attempt to equate the card framework template record 
of column 1 8 with the default member profile of claim 1 . The card framework template record 
describes the structure of the chip on the card and is referenced at various times during the smart 
card issuing process (column 18, first full paragraph). Claim 1 requires in a fifth step that this 
default member profile is modified based upon user responses to queries. There is no disclosure 
in Tushie that the card framework template record is ever modified based upon responses to user 
queries. 
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Therefore, it is respectfully submitted that this first step of claim 1 is not taught or 
suggested by Tushie as alleged in the Office action. 

Claim 1 requires as a second step 

providing a user with a plurality of queries regarding said smart card features, said 
queries originating from said software tool. 

The Office action alleges that Tushie discloses this step in column 6. 

Column 6 of Tushie at lines 42-56 discloses that the card issuer management system 150 
sends cardholder data to the smart card personalization system 100. The management system 
150 also determines the type of card issue, the card applications to embed and which 
personalization equipment to use. But, in the first place, neither the management system nor the 
personalization system is providing a user with queries regarding smart card features. There is 
no disclosure in Tushie showing that a user is presented with a number of queries and is then 
given a choice to respond to those queries. The management system of Tushie is simply using 
the prior art that is described in the background of the instant application. In other words, a user 
using the management system must manually decide on various options and then program 
software. Claim 1 provides an automatic method of choosing smart card features in order to 
personalize a batch of smart cards. 

In the second place, once the management system tells the personalization system which 
card to issue, which card application to embed and which personalization equipment to use, there 
is no opportunity for a user to change those settings. Claim 1 specifically requires that in a third 
step a user provides responses to queries, and in a fourth and fifth step those responses are 
matched with data values and the member profile is modified. Once the management system 
determines which card type to issue (for example) there is no opportunity for a user of the 
personalization system to change that particular option. By contrast, claim 1 specifically 
requires that the default member profile is modified using information originating from user 
responses to queries regarding smart card features. 

Therefore, it is respectfully submitted that this second step of claim 1 is not taught or 
suggested by Tushie as alleged in the Office action. 

Claim 1 requires as a third step 
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receiving from the user responses to the plurality of queries, said responses being 
received by said software tool. 

The Office action alleges that Tushie discloses this step at 152, and at columns 6 and 7. 
But, numeral 152 is simply a database of cardholder data. This is static information that does not 
change (such as cardholder name and cardholder account number); a user is not responding to 
queries. Also cited is column 6 at lines 53-56. Tushie discloses that the personalization system 
can also receive data from a person inputting the data from a telephone keypad. In other words, 
cardholder data can be received via a telephone keypad. But, there is no disclosure that this 
person is responding to a plurality of queries concerning smart card features. In fact, the person 
is simply inputting static cardholder data that would not change. Claim 1 specifically requires 
that the responses to these queries are used in a fifth step to modify a member profile. Any 
cardholder data received does not change and is not used to modify other data in the system. 

Also cited is column 7, lines 48-51. This portion also discloses that there are various 
ways of inputting cardholder data into the card issuer management system such as by a magnetic 
tape, floppy disk, telephone, et cetera. But, there is no disclosure that a user is inputting 
responses to a plurality of queries regarding smart card features. Someone might be inputting 
cardholder data, but cardholder data is not a response to a query regarding a smart card feature. 

Therefore, it is respectfully submitted that this third step of claim 1 is not taught or 
suggested by Tushie as alleged in the Office Action. 

Claim 1 requires as a fifth step 

modifying said default member profile using said matched output data values. 

As discussed above, Tushie does not disclose modifying a member profile using matched 
output data values that are derived from user responses to queries regarding smart card features. 
As discussed above, Tushie cannot disclose the default member profile because claim 1 
specifically requires that it be changed in the above a fifth step. Such a change of a default 
member profile is not disclosed in either Tushie or the Harms reference discussed below. 

Therefore, it is respectfully submitted that this fifth step of claim 1 is not taught or 
suggested by Tushie as alleged in the Office Action. 

Claim 1 requires as a sixth step 
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generating a personalization data file from said default member profile and said 
output data values. 

Harms describes a system to capture a consumer's name and other information through a 
drivers license or a government card in the form of a smart card, at a point of sale. The system 
includes a register, a bar code reader and an ID terminal. The invention is a way to capture 
information stored on the card using the ID terminal. The terminal can provide user prompts to 
the operator and can perform data capture, storage, receipt generation, data transmission, and the 
like. The ID terminal may be similar to the card reader. These devices may all be integrated into 
one device. The system described is one in which a consumer wanting to participate in a loyalty 
program with a retailer provides a license or other government ID card which is swiped to log 
the identity of the consumer at the ID terminal location. The clerk can also key in additional 
information on the consumer, the transaction, consumer's opinions, or other desired information 
as prompted on the ID terminal. The ID information captured by the terminal can be represented 
as an ID data record, such as shown in FIG. 2(A), including name, data of birth, etc. 

Purchase information is stored in a purchase data record. The central processing system 
processes a marketing record (a combination of ID data record and the purchase data record or 
visit information) by looking for a consumer ID number by searching a consumer database. If 
one is found, then the consumer has already been added to the database, so the record only needs 
to be added to the right section of the consumer record in the consumer database. In this manner, 
the consumer record is updated. If the consumer is not already in the database, an initial record 
is created. 

The Office Action references lines 17-24 of column 5 in Harms as teaching the step of 
providing a user with multiple queries about smart card features, the queries originating from a 
software tool. It equates the software tool recited in the claims (described as "personalization 
assistant tool 320") with the ID terminal described above in Harms in which a clerk keys in 
additional information into the ID terminal, like transaction data, consumer opinions, etc. This 
ID terminal and the keying in of information is not the same as entering queries regarding smart 
card features into the smart card personalization tool of the present invention. 

The Office Action also equates the step of the software tool receiving responses to the 
smart card queries from the user with the ID terminal where consumer information is gathered 
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from an ID card, such as a license. However, as explained above, receiving responses to queries 
regarding smart card features is not anticipated by capturing data from an ID card. 

The step of matching a response to a smart card feature query with output data value in a 
data preparation table of values as described in the specification is equated with a central 
processing system for checking if the consumer has a record in the consumer database (i.e., to 
see if the consumer has previously registered with the system). The step of matching a response 
to queries about smart card features with output data is not anticipated by a system that checks to 
see if a consumer has a record in a consumer database. 

The step of generating a personalization data file, as described in FIGS. 4 and 16 of the 
present invention, from a default member profile and output data values is equated with creating 
a consumer data record in Harms if one has not been created (i.e., consumer is not in the 
consumer database). A consumer record is created by accessing data from a government 
information database, which is inserted into an ID portion of the consumer's record. 

The Harms reference mentions smart cards once at column 5, lines 44 to 47: 

"For example, driver's licenses and the like may ultimately be replaced by so-called 

smart cards or the like. These cards are essentially small computers that are capable of storing 

and processing significant amounts of information." 

Consequently, Applicant believes that the Examiner's statement that "both of the 
references (Tushi and Harms) teach features that are directed to analogous art and they are 
directed to the same field of endeavor, such as, databases management systems, smart cards, 
and smart card input information." and that "[t]his close relationship between both references 
highly suggests an expectation of success" is not entirely accurate. Harms mentions smart cards 
once and only as an another form of a government ID card, whereas the presently claimed 
invention recites smart cards and smart card features at a level of detail not shown or taught by 
either of the cited references. 

Claim 1 1 requires many of the same similar steps as claim 1 and is believed patentable 
for the same reasons. 
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Reconsideration of this application and issuance of a Notice of Allowance at an early date 
are respectfully requested. If the Examiner believes a telephone conference would in any way 
expedite prosecution, please do not hesitate to telephone the undersigned at (612) 252-3335. 

Respectfully submitted, 
Beyer Weaver LLP 

/Rupak Nag/ 

Rupak Nag 

Registration No. 37,493 



Beyer Weaver LLP 
P.O. Box 70250 
Oakland, CA 94612-0250 

Telephone: (612) 252-3335 
Facsimile: (612) 825-6304 
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